1. Field of Invention
The present invention relates in general to the field of software testing. More specifically, embodiments of the present invention relate to system and method for quantitatively analyzing risk in risk-based software testing.
2. Description of the Background Art
A software product comprises several modules, each of which is different in terms of usability, architectural importance and code complexity. Conventionally, software testing is carried out with equal emphasis on all the modules/features of software. This method of testing leaves many defects undetected in modules that are relatively more important for the working of the software. Further, the testing cycle for software testing is stretched since time is needlessly spent on testing the modules where the probability of finding a defect is low. This practice not only results in a lower quality of software products but also reduces the productivity of testing resources.
The problems mentioned above are addressed by following the approach of ‘risk-based testing’ rather than that of ‘test everything with equal emphasis’. The aim of risk-based testing is to organize a test in such a way that the most important defects (i.e., the defects that severely affect the working of the software) are found with a certain extent of reliability. Further, the defects are desirably found in an early stage of testing. Risk-based testing involves identification of the relevant data, to assess the risky modules for possible chances of failure and damage. Based on the assessment, a test strategy is devised, so that the probability of identifying the most important defects is greatly enhanced.
In conventional risk-based testing techniques, the risk of finding defects in every module is qualitatively computed, not quantitatively computed. There are few drawbacks associated with conventional risk-based testing methods. In particular, conventional risk-based testing techniques do not take into account the characteristics of modules, indicating their relative importance, within the software. Consequently, the modules, which are more critical to achieve the desire output from the software, may not be given a higher priority during the testing, thereby reducing the probability of identifying defects in general and catastrophic defects in particular. Secondly, conventional risk-based testing does not account for the introduction of new modules in the software. In particular, there is no provision to determine the risk in case a new module is introduced at an architecturally important position in the new testing cycle of the software. As a result, risk-based testing may not identify this new module as a risky module, although it is a relatively new module, and hence unstable.